SpaceX timeline on how to walk something back (with receipts):

2019-06-23: “Occupy Mars.”
2019-06-24: “Moon 1st”
2026-02-09: “Shifted focus” to a “self-growing city” on the Moon “overriding priority” “Moon is faster.”
2030: Occupy LEO. (the quarterly OKR edition)
2032: Occupy the goalposts. (now in cislunar orbit)

I don’t disagree with your pessimism regarding the low bar, but I think you are missing a key distinction between developers and coders. When I was hired as a sysadmin by Raytheon three decades ago, the interview wasn't a test of whether I could follow a manual; my maths-heavy CS degree already checked the regurgitation box. The interview was about the size of Window's symbol table, the differences between Windows and Unix thread management, and a healthy dose of formal logic —the "minimum number of weighings to find the light marble" type of stuff. I got exactly one coding question, but it was Towers of Hanoi, not FizzBuzz. The distinction matters because it separates the sysadmin from the tech support worker, or to bring this back on point, the developer from the coder. FizzBuzz is a sanity check to see if you can handle syntax; Towers of Hanoi is a gateway to see if you actually grok recursion, state, and the stack. I agree with you here -- this problem started with script-kiddies savvy enough to download a hack getting hired as junior coders at some dotcom startup. But -- if you learn to code without learning formal logic, recursion, or memory management, you aren't a practitioner any more than a tech support worker is a sysadmin.

We aren't just losing literacy; we're losing the ability to maintain the scale that makes software valuable in the first place. Vibe coding allows a generation of low-education tech support-level coders to bypass the surfaces where the sysadmin-level professional developers of the open-source world live—documentation, bug reports, and community interaction. I think this distinction is important, because until AGI is realized (NB: LLMs are part of that, but they can't get there on their own IMHO) the entire FOSS community is on a fast track to a tragedy of the commons. The real risk is that vibe coding turns the entire industry into a giant Zendesk-style help desk...you aren't a practitioner; you're just a ticket-closer following an AI-generated script. If we stop rewarding the Towers of Hanoi level of literacy, the paper's software-begets-software loop works in reverse and FOSS dies.

It's great to run into a fellow traveler. I'm plowing my way through Iain M. Banks' Culture series and Neal Stephenson's Baroque cycle right now. I just finished the Honorverse, and before that it was a nostalgia tour through the Sprawl trilogy, the Dune novels (Frank's, not his son's cash grab stuff) and yes -- I periodically revisit RAH's Future History and Tolkien's Middle Earth. :) I like to go on reading quests -- ever since I stumbled across the wikipedia page for hugo award winning novels twenty years ago. All the Hugo awards winners, and then the top three finishers, then the Nebula Awards and their top 3 finishers, etc. I used to average about a book a week, but even technology can't fix my failing eyesight, though it helps a lot. I'm down to two or three a month now. I like history too, but for me it's cultural history -- I'm reading my way through the Five Foot Bookshelf as a side project. In today's greed-driven attention economy, the classics are arguably "alternate" history -- what was, and what still could be.

I had a fairly negative knee-jerk reaction to all the “AI scraping FOSS for training data is bad" comments surfacing in this thread. I realize that was because my FOSS instincts are still basically Stallman-era: public code is the point, reuse is the point, and the GPL exists to make sharing legally certain. If you put code out there under an open license, people reading it, learning from it, and building on it is not a bug. It’s the whole design. That should (and maybe legally does) include using open source code to feed your LLM. So if you’re like me and your first reaction is “scraping public FOSS is literally what we signed up for,” you are in good company. But after reading the thread and thinking it through, I think the better framing isn’t “is this allowed?” It’s “does this break the return channels that keep the commons alive?”

Classic open source reuse is coupled to participation signals. Humans learn from your repo, then they show up as users and peers. You get docs traffic, issues with repro steps, patches, bugfixes, packaging, wiki edits, community visibility, consulting leads, hiring signals -- many of which are monetizable. Even in the Red Hat world, the monetization was still tied to maintaining the commons: integration, QA, lifecycle guarantees, security backports, somebody answering the pager when the servers went south. The value loop stayed connected to the people doing the work. LLM training and agent-mediated coding can make that loop one-way, though. The paper shows why AI and FOSS are very likely on the fast track to a tragedy of the commons. Under copyleft, the theory has always been that reciprocity is the fence: distribute a derivative, inherit obligations. But LLMs don’t look like binaries, and distribution doesn’t look like shipping a tarball anymore. A company can potentially ingest a whole lot of FOSS pasture, sell the milk, and never walk through the gate where the shepherds are, not because they’re evil, but because the GPL’s reciprocity levers don’t map cleanly onto model weights the way they map onto distributing a program.

GPL’s big lever is reciprocity: if you distribute a derivative program, you have obligations to provide corresponding source, preserve notices, and so on. The legal question becomes: does a trained model, or the code it emits, count as a derivative work of the code it trained on in a way that triggers copyleft duties? That’s still legally murky. The recent Copilot litagation is a good example of why: the court forced plaintiffs to tie their claims to concrete legal hooks. Their DMCA-based missing attribution / removed copyright info theory was narrowed and ultimately dismissed because the outputs weren’t alleged to be identical copies with stripped notices, while contract and license-based theories were allowed to continue. The case doesn’t answer the “are model weights a derivative work?” question, but it does show how hard it is to make the old levers work on new artifacts, and why this remains unsettled instead of obvious.

The FSF is already trying to adapt the freedom framework to machine learning by arguing, in effect, that a genuinely “free” ML system should come with the materials that make the four freedoms real in practice, including access to the training data and related components, not just a black-box service and a license FAQ. The FSF's push for access to training data is a recognition of the paper's software-begets-software conclusions -- If seeds (training data) are locked away while the harvest (the model) is sold, the feedback loop that built FOSS turns into a one-way extraction valve. This is a direct acknowledgment by the keepers of the FOSS flame that machine learning breaks the original model of source available = freedom preserved. I heard Stallman speak several times back in the day, and even met him a couple of times. I suspect he’d nod at the shape of this problem and say: the law can be technically satisfied while the commons gets socially undermined, and we need to close that gap before the incentives rot out from under the people doing the work.

Open source doesn’t die because people reuse it. It dies when reuse becomes extraction at scale with no path back to sustainability.

That’s a real constraint, but it’s not a new one, and it’s not uniquely LLM-shaped. Every language that ever got traction had to clear table stakes that weren’t technical purity: documentation quality, tutorials, books, community examples, tooling, package ecosystem, and the ability for a new user to get from zero to “it runs” without burning a week. LLMs just become another on-ramp, not the whole highway. The paper actually argues that vibe coding isn't a "lagging indicator"—it’s a high-velocity shock. The authors show that adoption accelerates sharply once a usability threshold is crossed, meaning the "next Python" won't just struggle with LLM data; it will struggle because the paper's software-begets-software feedback loop is hitting a friction point. We’ve relied on a healthy ecosystem of existing code to lower the cost of building the next thing. If vibe coding starves the maintainers of that ecosystem, the foundation for the "next Python" evaporates before the first LLM even sees it.

Some won’t, sure. Some also won’t use a language without a formatter, a linter, a debugger, a good standard library, or a GitHub footprint with 10k stars and a massive tree of downstream dependencies. But “won’t” is not a law of nature. It’s a product of incentives and education. The way you get adoption is the way we always got adoption: make the first hour pleasant, make the first week productive, and make the first month feel like momentum. An LLM can help with that, but so can excellent docs and tools. Excellent docs and a senior coder with an open door policy still beat an hallucinating chatbot.

This is the part I agree with, with one missing piece: humans are in the exact same boat.

Programming languages have always had a training-data problem, because developers are not born with K&R hardwired into their cerebrum. They learn from corpora: textbooks, classes, tutorials, examples, codebases, mentors, review comments, and the slow accumulation of “how we do it here.” That’s literally why public schools exist, why CS departments exist, why apprenticeships and code review exist. Human understanding -- like an LLM -- depends on a huge, chaotic pile of prior artifacts that somebody took the time to order and categorize. So yes: LLMs that support developers need training data. This isn't a special indictment of LLMs; it’s the basic economics of learning for everyone—carbon-based or silicon-based.

Reasonable prediction, because “coding” used to mean more than typing: it meant translating vague intent into precise behavior, testing assumptions, handling edge cases, debugging, maintaining, and integrating. What’s changed is that the typing and scaffolding part got cheaper, and the translation layer got surprisingly good. The hard parts -- translating vague intent into precise behavior and handling edge cases -- didn’t disappear. The boundary just moved. What the paper is really warning us about is a tragedy of the commons. When we use AI to graze on open source software without leaving the footprints (bug reports, documentation visits) that maintainers monetize, we strip-mine the soil. The result isn't just automation; it's an increase in low-quality code that serves a creator's immediate needs but consumes volunteer time to review and fix. NB: low-quality doesn't mean broken in the sense of a compile error. It means code that solves one user's immediate problem but is economically irrelevant to everyone else. LLMs are essentially weaponizing "if it ain't broke, don't fix it" to produce mountains of code that works just well enough to avoid human review, but not well enough to sustain the ecosystem. We’re at risk of trading a robust public pasture for a billion private, brittle window-boxes.

This is where I push back hard, because it smuggles in a defeatist conclusion that doesn’t follow from the premises.

Humans still have to read and understand code. If anything, the ability becomes more important when code gets cheaper to produce. When output floods the zone, literacy matters more, not less. The paper points out that in our current baseline, users already receive roughly 1000 times more value than developers spend creating it. The big lever shifting the Nash equilibrium isn't that scale, but the demand-diversion channel. Vibe coding allows users to keep capturing that 1000x value while simultaneously stealing the engagement-based returns maintainers need to survive. That divergence is exactly what tips a virtuous loop into a recessive spiral.

And “without LLM support” is a choice, not a destiny. We can teach reading code the way we always taught it: deliberate practice, small programs, tracing, debugging, review, and the one that most of my professors used when I was an undergrad: “tell me what this does in plain English.” That's the one that tells them that the mental model is correct, that syntax has turned into meaning. LLMs can be excellent tutors, but they can’t be a substitute for comprehension, for the same reason a calculator can't grok the intuition behind the differential equation you just derived to model the physical system you’re about to simulate. They are a tool that scaffolds comprehension, not one that replaces it.

The real risk isn’t that a generation can’t read code. The risk is that we stop expecting them to. If we treat LLMs as training wheels instead of prosthetic eyesight, we get a generation that ships faster and understands deeper. If we treat them as a replacement for learning, we get brittle systems and brittle people. That’s not a technology outcome. That’s a cultural and educational choice.

This landed for me because I’m that person, just without the “coder” label.

I’m a sysadmin. If you widen the error bars enough to include shell scripting, sure, I “code,” but I’ve never had the patience or focus to be a real developer. Historically, that meant a lot of ideas stayed in the “would be nice” bucket unless they were directly tied to work and justified the learning curve.

Then I decided I wanted a tiny app to rearrange my desktop icons into a circle. Pure personal itch. Not a paycheck task. In the old world, that’s where the project dies: UI toolkits, window managers, APIs, packaging, all that overhead just to scratch a small aesthetic itch.

With LLM help, it didn’t die. I could iterate. I could ask for a first draft, test it, describe what broke, get a fix, repeat. I stayed in the role I’m actually good at: defining the goal, running the tests, spotting the edge cases, and insisting on reproducible behavior. The model did the “turn intent into code” part fast enough that my limited patience wasn’t the bottleneck anymore.

That doesn’t settle the tragedy-of-the-commons question in the paper. But it’s a real, concrete data point on the other side of the ledger: for people like me, “I’m not a coder” used to be a hard stop. Now it’s more like “I can be a maintainer of exactly one weird little thing I care about.”

This paper reads like any one of dozens of papers I had to digest for game theory classes back in college. Granted, that was thirty years ago and “optimization theory” has replaced game theory in the course catalogs, but the bones are the same: Nash is still hiding under the floorboards, tapping out equilibria with a broom handle. What the authors are really doing here is describing a potential tragedy of the commons, and dressing it in modern clothing. In their setup, open source is the shared pasture: maintainers are the shepherds doing the unglamorous work of reseeding and mending fence lines, and users are the cows. Vibe coding adds a new kind of cow, one that grazes constantly and at scale while leaving fewer of the footprints that normally pay the shepherds back: attention, bug reports with reproduction steps, patches, docs corrections, donations, consulting leads, the whole informal economy that kept a lot of projects alive. If that return channel dries up, the equilibrium shifts: fewer shepherds bother staying out in the rain, the pasture degrades, and everyone ends up worse off even though the short-term output looks amazing.

Nothing about that is conceptually novel. What’s novel is the pressure profile. I watched Red Hat go from an interesting way to monetize Linux in 1994 to a $34B IBM acquisition a quarter century later, which tells you there’s real money in selling stability, support, and risk management around a free codebase. But this paper is pointing at a different failure mode: not “open source can’t be monetized,” but “open source can be consumed so efficiently that the incentives to maintain it get vacuumed away.” The paper’s real kicker is what they call the software-begets-software effect. We’ve all seen this: a healthy ecosystem of libraries makes building the next tool trivial. That’s a virtuous cycle that helped FOSS explode. But the authors’ math shows this loop has a reverse gear. If vibe coding starves maintainers of the attention currency they need to keep the lights on, the ecosystem doesn't just stagnate—it contracts. Entry falls, variety shrinks, and the cost of building new software starts to climb because the foundation is rotting. We’re essentially using AI to strip-mine the very topsoil we need for the next harvest.

The models in the paper may be a bit too tuned to represent all of FOSS, sure. But where they’re right, they’re right in the way you can't really argue against. If vibe coding siphons off funding, leaving some critical cluster of FOSS coders unwatered long enough, FOSS could be on a fast track to that tragedy of the commons.

That’s not an argument, it’s astrology with a spreadsheet. Even if Vendor X faceplants into a crater, the workflow Chris is talking about doesn’t evaporate. These are prompts and scripts that turn “big diff, big context” into small, reviewable chunks. Swap the engine, keep the tooling. The kernel has outlived entire tech empires, compilers, VCSes, “next big things,” and at least three “Linux is doomed” decades. Tools that reduce reviewer fatigue stick around because reviewers keep using them, not because a quarterly earnings call went well.

Also: the LKML thread is about making AI review less magical by structuring it, scoping it, and forcing it to show its work. That’s basically the opposite of “bet the farm on a single vendor’s hype cycle.”

Correct in the most trivial way possible: lint won’t design your subsystem either -- and nobody claimed it would. This isn’t “let the chatbot be a maintainer,” it’s “use a tool to catch more bugs while humans stay responsible for architecture and interfaces.”

Kernel review is layered. Humans do the high-level “does this belong, does it fit, is the interface sane, does it age well?” work. Tools do the tireless “did you miss a refcount, a NULL check, a lock ordering hazard, a surprising call path” work. Chris is explicitly carving the diff into tasks, extracting call graphs, and even cross-checking lore and Fixes tags. That’s a checklist machine, not an architect. Complaining it’s not an architect is like complaining grep can’t write a better filesystem -- which Chris *obviously* can do... :)

If your model is “AI must find every non-toy security bug or it’s worthless,” then congrats, you’ve also just declared static analyzers, fuzzers, and humans worthless, because none of them are complete. In reality, we stack imperfect tools and get better outcomes. Syzkaller doesn’t understand architecture either, yet it finds terrifyingly real bugs. Sparse doesn’t grok interfaces, yet it saves us from type and annotation shooting us in the foot. Smatch doesn’t have to grok the dev's intent to catch patterns reviewers miss at 2AM.

AI review is the same category: a probabilistic pattern spotter that can flag suspicious deltas fast, especially when you constrain context, force targeted questions, and make it operate on extracted facts instead of vibes. That’s exactly what this informal RFC is doing, including extra rigor around syzbot reports.

if you don’t want to use the prompts, don’t. But don’t pretend “VC math scary” and “AI isn’t a maintainer” are substantive rebuttals to an RFC, even an informal one, about reducing token waste and catching more bugs with a structured, auditable review pipeline.

Just...no. You are confusing general intelligence with predictive accuracy. The paper defines proficiency specifically as next-token prediction (perplexity). If you had read the paper, you would have known this. How's that for an hypothesis? You don't get to dismiss an argument if you can't even get what you are dismissing right. In that specific metric, LLMs have mathematically surpassed the average human (see Shlegeris et al., 2022, cited in the paper). Unlike you, the paper isn't fantasizing about a future sci-fi AI; it is presenting empirical data on current models (like Pythia-6.9B). It measures that as their predictive accuracy exceeds human baselines, their internal processing mechanisms diverge from human brain activity. It’s a measured fact, not an hypothesis. Thwok -- ball's in your court.

Yep. Weather radar is already the found money channel for meteors and reentry junk, so squeezing a little more truth out of existing signals is always a win.
What made me grin about this article is how old-school the core idea is -- the Mach cone hitting the ground looks like a hyperbola if you plot the difference in arrival times of the signal at any sensors in the debris path. All it takes is some high school level algebra (conic sections ftw!) and a little creative thinking. I once caught a public talk at the Pima Air & Space Museum where an electrical engineer walked us through using USGS seismic stations to suss out a hypersonic track of something flying very fast across the desert southwest. He basically used sonic boom footprints based on this same idea about signal arrival times. His slide deck strongly suggested something doing Mach 6+ between Groom Lake in Nevada and Deer Island in southern California every couple of weeks. The punchline: he gave the whole talk standing under the wing of the museum’s SR-71. I asked during Q&A if that was a coincidence. He smiled: “Nope, not a coincidence.” (Crowd laughed, because of course they did -- Aurora and the X-39 were open secrets at the time.)

oblig XKCD

NOAA says we’ve hit G4 (Severe) geomagnetic storm levels, with a G4 watch still in play, plus an S4 (Severe) radiation storm riding along for the fun parts of physics that don’t care about our weekend plans.

I’ve been lucky enough to catch the aurora a handful of times in my sixty-four years on the planet, mostly back in my Reagan-era Air Force days. The one that branded itself into my brain was San Francisco: sitting in lawn chairs on the roof of my friend Joe’s place in the Marina, six stories up, watching ribbons and waterfall-cascades of light over the Golden Gate like the sky had decided to show off for the bay.

If you’ve never seen an auroral display in it's full glory, put it on your bucket list...let the universe remind you it has an art department.

No, it isn’t. The serious argument for transit is not “demand that people use buses,” it’s “make transit competitive enough that people choose it.” That’s the entire point of frequency, reliability, safe stops, shade/shelter, and not trapping buses behind single-occupant cars. Framing it as a moral scold is a neat rhetorical shortcut, but it’s not a description of how real transit planning works. It’s a libertarian caricature of it.

Correct, and that’s exactly why your next leap doesn’t follow. “There is a baseline cost” does not imply “therefore raising that cost is fine.” Saying “people already walk to transit” is not a blank check to increase first/last mile distance, especially when the increase is not evenly survivable across riders, cities, or seasons.

That’s just not true unless you define “advocates” as “a guy you got mad at in a city council meeting once.” Waiting time, walking distance, transfers, safety, and reliability are literally the core metrics transit agencies and planners obsess over. They quantify them. They model them. They spend entire budgets trying to reduce them. Pretending nobody treats them as important is how you smuggle in the conclusion that riders’ costs don’t matter, without having to defend it.

Also: “advocates of buses” is doing a lot of work here. If what you mean is “commie-pinko socialists,” you can just say “people who think a functioning city has social obligations,” because that’s what you’re really trying to sneer at.

What’s different is that one is the admission price of using the service, and the other is a policy decision to raise that price. “You already pay a fee” is not a principled argument for “we should increase the fee.”

And it’s not “an extra block” in the only places this debate matters. In Tucson or Phoenix in August, on cracked sidewalks, hostile crossings, and zero shade, that “extra block” is not a neutral rounding error. For an elderly rider, a disabled rider, someone carrying groceries, someone with a stroller, someone with a bad heart, it’s a barrier to entry and sometimes a health risk. You don’t get to declare it negligible by imagining a perfectly abled rider in perfect weather and calling that realism.

Here’s the part you’re trying to skate past: if stop consolidation comes with reinvestment, it can be defensible. If the savings buy higher frequency, better reliability, real stops with shade/benches/lighting, safer crossings, and actual priority in traffic, then you can argue it improves generalized cost.

But that’s not what this article is selling. It’s selling “cheap, fast, no politics,” which usually translates to “we made the ledger better by moving costs onto riders.” That was the point of my post -- calling this article out for what it is advocating: a libertarian pipe dream camouflaged as "more efficient government." The article all but had "Approved by DOGE" watermarked across each page.

So yes: walking to transit is a cost. That’s why you don’t casually increase it and call it “efficiency” unless you’re ideologically committed to one specific miracle: the spreadsheet improves while the rider absorbs the consequences.

Steam’s updated AI disclosure policy is exactly the kind of policy you write when you’ve had to operate a platform at scale: focus on what the player actually consumes, and treat “live generation” as a different beast than “we used AI in the build pipeline.”

If a developer used an AI code helper, who cares? That’s a hammer, not a house. Steam seems to agree: gamers, in general, don't seem to care whether AI was used by devs to build the game.

But “AI content generated during gameplay” absolutely deserves its own checkbox, because it’s not a shipped asset, it’s a content faucet. A static pile of art/dialogue can be reviewed the same way anything else can. A runtime generator can create novel text/images/audio on demand, after release, in combinations nobody tested, reviewed, or even imagined.

And yes: Rule 34 applies. Sad, but true:

If it can be sexualized, it will be.
If it can be used to harass, it will be.
If it can be steered into “oops that’s copyrighted,” it will be.

Not because gamers are uniquely depraved, but because scale turns edge cases into Fox News chyrons and class-action law suits.

From the Steam legal department's perspective, the problem is painfully practical:
1) Their normal review process can’t verify content that doesn’t exist yet.
2) The Steam Distribution Agreement still expects “no illegal/infringing content,” whether it was handcrafted, procedurally generated, or hallucinated into existence at runtime.
3) DMCA-style cleanup is a terrible fit for infinite output. “We’ll patch it later” is not a compliance strategy, it’s a confession that you broke the law.

So Valve draws a clean line:
- Pre-generated AI content: disclose it, and it gets reviewed like any other content.
- Live-generated AI content: disclose it, AND tell them what guardrails you’ve put in place so the thing doesn’t generate illegal content on demand.

That’s not anti-AI. That’s not a “ban.” It’s the minimum viable paperwork you need when you’re selling games in a world where a text box can become a liability generator.

IIf you ship a book, Steam can read the book.
If you ship a game with an AI generator in it, Steam wants the label on the crate and the safety interlocks described, because some players are going to go 4chan with it the moment it boots.

Yes, and airplanes don't flap their wings. That hasn’t stopped anyone from flying. LLMs don’t model biology—they model language. In fact, the paper actually argues that high-performance LLMs are diverging from human brain activity, not converging. It explicitly notes that "correlation between next-word prediction... and brain alignment fades once models surpass human language proficiency." The paper suggests LLMs solve linguistic tasks using mechanisms distinct from the human brain once they scale past a certain point. So you are right that they function differently, but wrong to imply this makes them ineffective. They are engineering a different path to similar (or superior) linguistic outcomes.

Sure—and humans also don’t need to tokenize input or normalize embeddings across 4K context windows. LLMs aren’t trying to replicate how humans learn; they’re engineering a different path to similar linguistic outcomes. Yes, the data scale is immense—but that’s the price of not having a body, a childhood, or a caregiver. LLMs bootstrap from scratch using raw text alone—no multimodal cues, no affective modeling, no theory of mind—just prediction and gradient descent. Given those constraints, it’s astonishing how well they perform.

Also, your “single textbook” theory of human development misses just how scaffolded and embodied natural language acquisition actually is. Kids don’t learn to read from a textbook—they acquire language through years of immersion, social cues, repetition, and multimodal feedback, all before formal literacy even starts. And unlike LLMs, human brains hardwire their primary language in early development—by age six, those linguistic pathways are largely fixed, which is why second-language acquisition is so much harder later in life. LLMs don’t have that bottleneck. You can train them in Hindi, then in English, then in code-switching Hinglish, and they won’t blink. The architecture doesn’t care—it just maps tokens to a Hilbert space, and then converges on a contour in that space. Flexibility like that isn’t a flaw; it’s a feature.

True—humans can learn during deployment, but we’re also really good at forgetting mid-sentence, and updating our priors based on vibes. Humans have distinct developmental phases, and our neuroplasticity drops significantly with age. LLMs don’t have continual learning in the weights (yet), but we already have retrieval-augmented generation (RAG) and adapters (LoRA) that allow real-time updates without full retraining. The architecture for streaming models and fine-tuning during inference is already on the roadmap (see: retrieval-augmented generation, LoRA adapters, and reinforcement learning with human feedback)

Also, cognitive dissonance? You’re swimming in it. You demand biological parity while rejecting the very differences that let these systems scale. You need to pick a lane, here.

You are confusing architectural recurrence with functional recursion. May I suggest Hofstatder's excellent "Godel, Escher, and Bach" for a lucid, high-school level primer on recursion? You mentioned Hofstatder below; I can see why you are confusing these two concepts if you've only read his "I Am a Strange Loop." without really understanding mathematical recursion. Transformers are indeed feed-forward, but their inference process is auto-regressive—the output of step T feeds back into step T+1. Techniques like chain-of-thought prompting or scratchpad reasoning) explicitly induce recursive reasoning steps.

Not even Roger Penrose would call that the litmus test for strange loops. At least not in Hofstadter’s strictest sense. But when a system trained on human data starts generating output that humans can’t reliably distinguish from their own thoughts (this is exactly the point Turning makes with his imitation game) and starts studying itself to refine future versions—that’s not far off. Hofstadter and Dennett echo this in "The Mind''s I". And Dennett is even more explicit about this: humans are “a bunch of tricks” running on meat hardware—a statement that’s becoming eerily relevant to LLMs. If Turing showed us how imitation reveals cognition, Hofstadter showed us what it looks like when cognition loops back on itself. Strange loops aren’t measured by the wiring diagram—they emerge from self-reference and representational feedback. And by that standard, today’s LLMs are flirting with loopiness. Turing gave us the imitation game. Hofstadter gave us strange loops. LLMs didn’t ask to be players in either game—but they’re getting eerily good at both.